On Sat, Apr 25, 2015 at 11:44 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

That sounds clever.

I don't exactly see how a simple list of X,Y,Z points can define an obstruction.  Seems like it would need to define the top of a 3D rectangular block  Maybe 3 or 4 xy points and a height?  Anyways I'll assume you figured something out that would work.

Yes, I oversimplified.  Each 3-d "keep out" block would be defined by its min and max coordinate for X and Y, and max Z.

 

It seems to me another problem could be a move from a legal position to another legal position still causing a crash.

Good point.  It would have to consider the allowable envelope based only on the point that it is currently at, not try to figure out whether the current and dest positions are ok.

 

With KMotionCNC the Soft Limits are implemented in a two fold approach.  #1 KMotionCNC uploads the Soft Limits at the beginning of a Job and flags any move that would move into the limits to prevent the motion from starting in the first place.  #2 KFLOP monitors the real time commanded destinations and FeedHolds on any destination inside the Soft Limits and currently moving further into the Soft Limit.

By "inside the soft limits" do you mean outside the allowable envelope?  I ask because it does not seem to honor soft limits for Move() or Jog() called within the kflop - it happily hits the limit switch, so I have to program my own checks for internally generated uncoordinated motion.

 

The "map" would have to be incorporated directly into KMotionCNC for the preventative nature of #1 to work properly. 

So I think it would be simplest to just leave Soft Limits at the full extents, and have your monitor program running in KFLOP perform the FeedHold itself.

Seems like feed hold is the way to go then.  Although I might also tweak the limits because other routines in the kflop look at that, such as the MPG jogging.  It would be nice to have jogging stop nice and smooth at the dynamic limits no matter how recklessly some operator is cranking the dial.

 

On a related issue you might want to factor in velocity  Our Soft Limits only trip Feedhold after the limit has been exceeded.  We haven't yet figured out a simple way to factor in current velocity and current acceleration and the velocity, acceleration, and jerk limitations to determine that the axis is at a point where it would necessarily enter the Soft Limits at some point in the future (can you think of a fast way to do this?).  If you are running as a separate Thread then calculation time might not be as critical and you could afford to do this.

Since stopping distance is proportional to the square of velocity (for a constant accel) - so they say at driving school, anyway - one approach would be to calculate a virtual point ahead of the current position, per axis, as some factor of v^2/a plus the current tool radius.  That point would then be tested for entry to any keep-out volume.  Maybe add a fudge factor to account for jerk, or simply set jerk to infinity before feed hold (it's an error condition anyway, so doesn't matter if the machine goes thud).

There is a last_vel field in the channel struct (does that do what I think it does?), or if not that then I can just keep track of position deltas, as in the tangential knife demo.

Well thanks for the help so far; this should be an interesting exercise.

Regards,

SJH

 

Regards

TK

Group: DynoMotion	Message: 11443	From: Tom Kerekes	Date: 4/26/2015
Subject: Re: Dynamic soft limits

Hi SJH, >>>>>By "inside the soft limits" do you mean outside the allowable envelope?  I ask because it does not seem to honor soft limits for Move() or Jog() called within the kflop - it happily hits the limit switch, so I have to program my own checks for internally generated uncoordinated motion.   Yes - outside allowable envelope. That shouldn't be the case.  Independent axis motions (uncoordinated) into Soft Limits should also trip a Feed Hold.  The axis does need to be defined as part of the Coordinated Motion System however.  We are trying to fix a bug regarding resuming independent motion and also another bug regarding moving out of Soft Limits.  But basically the Soft Limits should currently be honored. >>>>>Since stopping distance is proportional to the square of velocity (for a constant accel) - so they say at driving school, anyway - one approach would be to calculate a virtual point ahead of the current position, per axis, as some factor of v^2/a plus the current tool radius.  That point would then be tested for entry to any keep-out volume.  Maybe add a fudge factor to account for jerk, or simply set jerk to infinity before feed hold (it's an error condition anyway, so doesn't matter if the machine goes thud). I was thinking it might make sense to do a "full deceleration" test as you describe.  If instant and full deceleration would still result in exceeding the soft limit then we could go ahead and trigger the feed hold.  The result wouldn't be perfect but should result in much less distance into the soft limit than not doing anything. >>>>>>There is a last_vel field in the channel struct (does that do what I think it does?), or if not that then I can just keep track of position deltas, as in the tangential knife demo. Yes last_vel is the most recent instantaneous velocity of the trajectory (Destination) in counts (or steps) per second. Regards TK